Changing owner of files: Windows vs Linux (or Why I hate Windows)

Hello all,

This is a rant with supporting code illustrating the amount of work it takes to change the owner of a file on Windows and on Linux. If you don't want to hear me bitch, skip the rest of this node. If you really don't want to hear it, vote this node down and I'll take the hint. :)

I sent this email to the other (primarily Linux Perl) developers in my company. I thought I'd post it here so all can partake of the schadenfreude:

Here's how you change a file owner in Windows (for which you have to use C):

        // #includes omitted for the sake of sanity
        HANDLE token;
        char *filename = "somefile.txt";
        char *newuser = "someuser";
        DWORD len;
        PSECURITY_DESCRIPTOR security = NULL;
        PSID sidPtr = NULL;
        int retValue = 1;

        // Get the privileges you need
        if (OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILE
+GES, &token)) {
            SetPrivilege(token, "SeTakeOwnershipPrivilege", 1);
            SetPrivilege(token, "SeSecurityPrivilege", 1);
            SetPrivilege(token, "SeBackupPrivilege", 1);
            SetPrivilege(token, "SeRestorePrivilege", 1);
        } else retValue = 0;

        // Create the security descriptor
        if (retValue) {
            GetFileSecurity(filename, OWNER_SECURITY_INFORMATION, secu
+rity, 0, &len);
            security = (PSECURITY_DESCRIPTOR)malloc(len);
            if (!InitializeSecurityDescriptor(security,
SECURITY_DESCRIPTOR_REVISION))
                retValue = 0;
        }

        // Get the sid for the username
        if (retValue) {
            char domainbuf[4096];
            DWORD sidSize = 0;
            DWORD bufSize = 4096;
            SID_NAME_USE sidUse;
            LookupAccountName(NULL, newuser, sidPtr, &sidSize, domainb
+uf, &bufSize, &sidUse);
            sid = (PSID)malloc(sidSize);
            if (!LookupAccountName(NULL, string, (PSID)sid, &sidSize, 
+domainbuf, &bufSize, &sidUse))
                retValue = 0;
            }
        }

        // Set the sid to be the new owner
        if (retValue && !SetSecurityDescriptorOwner(security, sidPtr, 
+0))
            retValue = 0;

        // Save the security descriptor
        if (retValue)
            retValue = SetFileSecurity(filename, OWNER_SECURITY_INFORM
+ATION, security);
        if (security) free(security);
        if (sid) free(sid);
        return retValue;
[download]

Here's how you do it on Linux (for which you can use perl):

        my $filename = 'somefile';
        my $newuser = 'someuser';

        my $newuid = getpwname($newuser)[2];
        my $oldguid = stat($filename)[5];
        return ($newuid && chown($newuid, $oldguid, $filename));
[download]

Of course, you could do the Linux in one fairly readable line, if you were so inclined...

        my $filename = 'somefile';
        my $newuser = 'someuser';

        return getpwname($newuser) && chown(getpwnam($newuser)[2], sta
+t($filename)[5], $filename);
[download]

Some of the code bloat comes from the poorly designed API, and some comes from the memory management you have to do in C. Note also that this procedure is very poorly documented; I had to pick through dozens of code fragments, Microsoft help files, and newgroup entries to get this. I got the perl code in a couple minutes from the camel head book.

The upshot? C takes a long time to develop in and sucks for some things (feel free to show these pieces of code the next time someone asks why C takes longer to develop in than Perl). And Microsoft just plain sucks.

-Ton

btw: I am aware that there is a Win32::Perms module available that does this. Sadly, the Perms module fails at setting access control lists. I therefore had to write my own, and figured I should have my module do the owner/group stuff as well.

Comment on Changing owner of files: Windows vs Linux (or Why I hate Windows) Select or Download Code

Replies are listed 'Best First'.
Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by mothra (Hermit) on Apr 07, 2001 at 01:31 UTC
I'm one who gladly voted this down. Anyone who writes a meditation with $title =~ /.hate.windows./i in it is just asking to be called an XP whore. But I'll give you the benefit of the doubt and pretend that wasn't your intent... That said, why would you hate an entire OS because of the amount of lines it takes you to change the permissions of a file? That makes less than no sense, and it's likely that your first shot probably isn't nearly the best. Should I hate Linux because it's not possible to legally view the contents of a web page without using the fonts from an installation of MS Windows? Or why don't I choose to hate it because it can't do anything to provide me the graphic quality that DirectX can? Why don't we compare the amount of lines it takes to just create the widgets* of a GUI program in Perl vs. that "language for stupid people" VB? Should I use that as a basis for why Perl sucks? The point is that dismissing the good points of any tool (whether it be an OS, language, IDE or otherwise) because you found something that sucked is a sign that you probably haven't taken the time to match the tool against the task or you're being overzealous. Every language/IDE/OS sucks in some way or another (in fact, usually in at least 10 different ways).	[reply]
Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by ton (Friar) on Apr 07, 2001 at 02:14 UTC
It was not my intent to be an experience point whore; my intention was to give a case study of Microsoft's "security through obscurity" paradigm with respect to Windows. Let me summarize my points: Microsoft's Windows API contains far too much administrative overhead. All of the calls API calls I listed are actually needed to change the owner; if you don't believe me, feel free to paste the code into your copy of VC++, comment out any section, and execute it a few thousand times. (Multiple executions are needed to show memory leaks in the event that you comment out the "free" statements.) This overhead is very poorly documented. I spent about a day going through various WinAPI books, code discussion groups, etc. to get the code I posted above. I'm sure that there are sites that I didn't check, and one of them might have similar or better code than what I've listed. But NONE of those sites are as convenient as the Camel or the Camel head. As far as your points are concerned, Your point regarding computer languages is entirely valid. Languages are optimized for different things, and they do indeed suck when you don't play to their strengths. But my rant is not against C, but against Windows. Actually, it's a rant against the Windows API, which appears to be optimized for obscurity. I should have titled this section "Why I hate the Windows API". My bad. How do you propose that I "match the tool against the task" of changing a file's owner? By convincing my users to throw out their Win32 boxes and get Linux ones? (wow... that thought just sent me to a happy place :) ). This example of API overhead is not an isolated case. I've been programming in Windows API for a few years now, and it's always been a huge mess for anything other than popping up message boxes. (Anyone remember when Win32 first came out, and the nightmare of syncing short and long filenames?) And yes, this is not remotely constructive, and yes, it is childish, and yes, it is little more than an online theaputic temper tantrum. Which is why I prefaced it as such. -Ton btw: in the event that anyone does try to compile my code, I omitted the fact that "SetPrivilege" is a subroutine that I wrote, not a windows API call. Here's the code for that: int SetPrivilege(char *privilege, int enable) { TOKEN_PRIVILEGES tp; LUID luid; HANDLE token; if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES +, &token)) return 0; if (!LookupPrivilegeValue(NULL, privilege, &luid)) return 0; tp.PrivilegeCount = 1; tp.Privileges[0].Luid = luid; if (enable) tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; else tp.Privileges[0].Attributes = 0; // Enable the privilege or disable all privileges. return AdjustTokenPrivileges(token, 0, &tp, NULL, NULL, NULL); } [download]	[reply] [d/l]
Re: Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by mothra (Hermit) on Apr 07, 2001 at 02:59 UTC
Before anything else, I have to ask: why didn't you just use this program? You're already forgetting portability by using the Win32 API, you might as well just save yourself the 40 lines and tell another program to do the work. Microsoft's Windows API contains far too much administrative overhead... Hey, haven't you ever wanted to win a million dollars? The day programming becomes easy, I'll write you the cheque. This overhead is very poorly documented. The nature of any kind of library/module/program's documentation is that sometimes the more obscure aspects are not well documented. Sadly sometimes even the commonly used features aren't always documented (feel free to point me to some serious Win32::GUI documentation). But NONE of those sites are as convenient as the Camel or the Camel head. Can you point me to where in the camel it tells me how to implement graph algorithms for creating wizards? (Think I'm being anal? We do this at work, but using a tool that is not Perl). Or how about the part about creating editmasks in text controls? I would want to do this all the time, but haven't been able to find out how it could be done (and no longer care, because I wouldn't use Perl for serious GUI programming). The point is, it's in the Camel because changing an owner of a file is something Larry thought a fair number of readers might want to do. If the authors of the books on the Win32 API forgot to mention a simple way of changing ownership of a file, I'd forgive them. It's certainly something I can't even think of needing for any of the Windows programs I've written, and currently work on (and yet, I've done it on Unix systems, just because I could). How do you propose that I "match the tool against the task" of changing a file's owner? If this is the entire purpose of the program then you shouldn't have written it because it's already been done. If it's just a tiny piece, I wouldn't think twice about it. Move on. This example of API overhead is not an isolated case. I've been programming in Windows API for a few years now, and it's always been a huge mess for anything other than popping up message boxes. Eeek, wait until all the other Windows programmers find this out!	[reply]
(jcwren ) Re: (4) Changing owner of files: Windows vs Linux by jcwren (Prior) on Apr 07, 2001 at 03:07 UTC
Re (tilly) 5: Changing owner of files: Windows vs Linux by tilly (Archbishop) on Apr 07, 2001 at 05:00 UTC
Re: Re: Re: Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by ton (Friar) on Apr 07, 2001 at 03:28 UTC
Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by rchiav (Deacon) on Apr 07, 2001 at 03:42 UTC
This comes across as very one sided and biased. I could argue that I hate Linux (which I don't) because you have to chown/mod/grp files as often as you do. I've never had a need to do this under windows. Good group design makes this virtually uneeded. Yet I find myself constantly having to fiddle with ownership on Linix. Microsoft intentionally did not make a chown type command because it's against the design of their security policy. But do I dislike Linux because of this? No. And on top of all of this, you could just use "cacls" and a version of chown compiled for win32 systems along with various other techniques. Rich	[reply]
Re: Changing owner of files: Windows vs Linux (or Why I hate Windows) by blm (Hermit) on Sep 10, 2002 at 04:22 UTC
What is it that Win32::Perms fails at? ps I don't think that I will be joining u in the sixth circle. At least I hope not.	[reply]


Syntactic Confectionery Delight
	PerlMonks