Our college assigned us a homework for Unix.

We have to change the permission of a newly created file to 222 without using chmod.

Decrease the file permission by "222" [Do not use chmod command]:

Personally to me, I can use Ruby:

ruby -e "File.chmod(0222, File.join(Dir.pwd, 'F2'))"

But these kinds of solutions are probably not allowed.

Also, here I got the question: How to chmod without /usr/bin/chmod?

But the answers were a bit different. They were discussing about restoring the deleted chmod binary.

How can I change the permission of a file without chmod?

  • 1
    "these kinds of solutions are probably not allowed" Ask and find out. – muru Aug 26 '19 at 5:52
  • Well, I am not in the college, and I have to submit it tomorrow! Even no programming languages are allowed to do this... Is there any chmod alternative that will run on Unix? – S.Goswami Aug 26 '19 at 6:04
  • 1
    you could use stat to get the current perms, then "decrease" them by 222 (e.g. by AND-ing them with "not 222"), then install -m "$newperms" "$origfile" "$tempfile" and mv -f $tempfile "$origfile" (but this will break any hard links) – cas Aug 26 '19 at 6:11
  • That's helpful. But it doesn't seem clean to get the permission, deduct the permission by 0222, then change the permission. But we have to deal with that! – S.Goswami Aug 26 '19 at 6:20
  • 1
    @S.Goswami ilkkachu's answer contains all the hints you need. Note that you are probably not being asked to change the permissions on any existing files (you don't seem to quote that bit verbatim though), only on files that you create. – Kusalananda Aug 26 '19 at 6:27

Note that your specification explicitly talks about newly created files. You couldn't even use chmod to change that, since a new file would have some set of permissions when created, before you could use chmod on them.

Also, while that Ruby script doesn't run the chmod command/utility, it does use the same underlying system call, so it's practically the same thing. If it were me, I wouldn't allow that.

Without giving out the full answer, I'd suggest looking at what the man page for open() says about the permissions of the created file:

The mode argument specifies the file mode bits be applied when a new file is created. This argument must be supplied when O_CREAT or O_TMPFILE is specified in flags; if neither O_CREAT nor O_TMPFILE is specified, then mode is ignored. The effective mode is modified by the process's umask in the usual way: in the absence of a default ACL, the mode of the created file is (mode & ~umask). Note that this mode applies only to future accesses of the newly created file; the open() call that creates a read-only file may well return a read/write file descriptor.

The following symbolic constants are provided for mode:

S_IRWXU 00700 user (file owner) has read, write, and execute permission


Also note that the part you quoted said to "decrease the permissions by 222", not to 222. That's also important regarding the function I'm thinking of.

Since it was already mentioned in the comments

I'm thinking of umask, which limits the permissions of newly-created files. It should be a standard feature, and should work the same in Linux and in DragonFly.

Of course, all of this is just my interpretation of that assignment. There's no way for any of us here to know for sure what the correct answer is in the opinion of your teacher/professor, especially since sometimes the answers given by professors are not even the correct ones.

  • I don't see this matching up with the manpage of open in DragonFly BSD... – S.Goswami Aug 26 '19 at 11:00
  • 2
    Yep, the DragonFly BSD man page says: "... In this case open() and openat() require a third argument mode_t mode, and the file is created with mode mode as described in chmod(2) and modified by the process' umask value (see umask(2))." – ilkkachu Aug 26 '19 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.